UpdateRecurringPaymentDetails

The UpdateRecurringPaymentDetails web service XML- or JSON-based information exchange systems that use the Internet for direct application-to-application interaction. These systems can include programs, objects, messages, or documents. enables an external client system to update the recurring payment type for a given Account In the Cloud Monetisation Platform, a billing entity that can be used to manage payments on one or more subscriptions or payments for services. An account can hold details such as payments or invoices. Number.

For example, this could be changing Direct Debit Payment Type to Credit Card or vice versa.

Updating a recurring payment type is a two-step process:

• The user A person with the capability to log in to the CMP GUI software, such as a customer service advisor or agent. cancels the existing payment type of the Account.
• The user passes in a valid CMP Converged Monetisation Platform. The MDS Global product that supports customer care and billing for digital service providers. Account Number, new recurring payment type and new payment details to add the new payment type of the Account.

This UpdateRecurringPaymentDetails web serviceshould be used in conjunction with the Query Account Details Service.

Invalid requests, such as attempting to change to another recurring Payment Type (for example Credit Card) without first cancelling the existing payment type (for example, Direct Debit), are rejected with an error message.

CMP supports two types of direct debit schemes: BACS Bankers Automated Clearing Services. A system in the United Kingdom for making payments directly from one bank account into another. and SEPA. Only one scheme can be used at any one time.

UpdateRecurringPaymentDetails Request

The UpdateRecurringPaymentDetails tag instructs the Account Service to update recurring payment details. This request contains the following elements:

Element Name	Content Type	Description	Required?
ExternalReference	String69	The client may use this identifier to correlate the request and the response.	Optional
AccountNumber	Integer8	Number of the existing Account which the change to recurring payment applies to.	Mandatory
PaymentType	String6	Automatic Payments for example: DEBIT = Debit or CREDIT = Credit.	Mandatory
PaymentTerm	String3	The agreed terms of payment, e.g. within 14 days of invoice date.	Optional
PaymentDetails	Container	Choice of: PaymentCardDetails DirectDebitDetails See PaymentDetails Request Container for details.	Optional
LastAmendedDate	dateTime	YYYY-MM-DDThh:mm:ssZ This needs to be the last amended date returned by calling the QueryAccount web service passing in a dataset dependent on the type of amendment: If the Account is changing from a Manual (e.g. Cheque, Giro, etc) payment type to either a Direct Debit or Payment Card, the Last Amended Date supplied must be that from the Account Query, Payment Details dataset. If the Account is changing from either Direct Debit or Payment Card to Manual, then the last amended date supplied must be that from the Account Query, Basic dataset. If the attributes of a Direct Debit or Payment Card are changing, e.g. updating the Bank Account Number, then the Last Amended Date supplied must be that from the Account Query, Payment Details dataset.	Mandatory
AuditRecord	Container	See AuditRecord Request Container for details.	Optional

PaymentDetails Request Container

The PaymentDetails request container has the following elements:

Element Name	Content Type	Description	Required?
PaymentCardDetails	Container	Choice of: PaymentCard CancellationInformation PaymentCardToken See Payment Card Details Request Container for details.	Mandatory
DirectDebitDetails	Container	Choice of: DirectDebit CancellationInformation See DirectDebitDetails Request Container for details.	Mandatory

PaymentCardDetails Request Container

The PaymentCardDetails request container has the following elements:

Element Name	Content Type	Description	Required?
PaymentCardToken	Container	The PaymentCardToken container will only be accepted if the PCI Compliance Toolbox feature is switched on. See Payment Card Token Request Container for details.	Mandatory
CancellationInformation	Container	See CancellationInformation Request Container for details.	Mandatory

PaymentCardToken Request Container

The PaymentCardToken request container has the following elements:

Element Name	Content Type	Description	Required?
CardReference	VARCHAR(100)	The tokenised string representing the card.	Mandatory
CardNumber	String4	Last four digits of the card number.	Optional
NameOnCard	String20	The name that appears on the card.	Optional
StartYear	String2	Start year on the card.	Optional
StartMonth	String2	Start month on the card.	Optional
ExpiryYear	String2	Expiry year on the card.	Optional
ExpiryMonth	String2	Expiry month on the card.	Optional

If the PCI-compliant toolbox feature is turned on, any card details not found in this container are rejected. These are as follows:

Element Name	Content Type	Description	Required?
CCDCCardNumber	String20	The actual number of the credit or debit card.	Optional
NameOnCard	String20	Name of the cardholder exactly as displayed on the card.	Optional
StartYear	String2	Start year on the card.	Optional
StartMonth	String2	Start month on the card.	Optional
ExpiryYear	String2	Expiry year on the card.	Optional
ExpiryMonth	String2	Expiry month on the card.	Optional
CreditSecurityCode	String6	The card security code used. On many card types it is the last group of digits on the signature panel at the back of the card.	Optional

CancellationInformation Request Container

The CancellationInformation request container has the following elements:

Element Name	Content Type	Description	Required?
ReasonCode	String4	The valid cancellation reason depends on what is being cancelled, e.g. Credit Card/ Debit Card etc. In the case of a payment card (credit card/debit card) the valid reason codes are defined in the Core Reason Type Maint. screen keyed by a type code of CDCAN.	Mandatory
CancellationDate	Date	YYYY-MM-DDZ If a cancellation reason code has been entered then a cancellation date must also be entered.	Mandatory

DirectDebitDetails Request Container

The DirectDebitDetails request container has the following elements:

Element Name	Content Type	Description	Required?
DirectDebit	Container	See Direct Debit Request Container for details.	Mandatory
CancellationInformation	Container	See CancellationInformation Request Container for details.	Mandatory

DirectDebit Request Container

The DirectDebit request container has the following elements:

Element Name	Content Type	Description	Required?
DDAccountName	String60	The name of the account or account holder.	Optional
BankAccountNumber	String20	The bank account from which the payments will be made. This is applicable to BACS.	Optional
BankSortCode	String20	The code of the bank branch which holds the account.	Optional
NameOfPayer	String30	The name of the person instigating the direct debit. Use the following format for this field: "First name<space>Last name"	Optional
DateMandateReceived	date	Choice of: <Value> <Clear> This is the date that the DD mandate was received. For electronic forms of DD Mandate this should be set to the current date. For paper mandates, it is the date that the mandate was received by the relevant back office individual. YYYY-MM-DDZ	Optional
DirectDebitSetupMethodCode	String6	The unique code for the set up method used. For example, PDD - Paperless Direct Debit (Phone).	Optional

CancellationInformation Request Container

The CancellationInformation request container has the following elements:

Element Name	Content Type	Description	Required?
ReasonCode	String4	The valid cancellation reason depends on what is being cancelled, e.g. Credit Card/ Debit Card etc. In the case of a payment card (credit card/debit card) the valid reason codes are defined in the Core Reason Type Maint. screen keyed by a type code of CDCAN.	Mandatory
CancellationDate	Date	YYYY-MM-DDZ If a cancellation reason code has been entered then a cancellation date must also be entered.	Mandatory

AuditRecord Request Container

The AuditRecord request container has the following elements:

Element Name	Content Type	Description	Required?
UserId	String10	User ID associated with the profile. It is the ID that the calling program will use on the records that are created.	Mandatory
Program	String10	The Program Name should be hard coded in the calling application so as to uniquely identify that application.	Mandatory

UpdateRecurringPaymentDetails Response

The UpdateRecurringPaymentDetails response is the response to the UpdateRecurringPaymentDetails Request. This contains the following elements:

Element Name	Content Type	Description	Required
ExternalReference	String69	Returned unmodified in the response. The client may use this identifier to correlate the request and the response.	Optional

Failure Scenarios

Bank account validation failure scenarios are in place for the UpdateRecurringPaymentDetails web service.

Examples are given below:

Fault-Response-CMP-Setup

Fault-Response-Timeout

Fault-Response-Multiple-Third-Party-Faults

Fault-Response-Negative-Validation-Result

Fault-Response-No-Connection

Fault-Response-Precheck